1. Field of the Invention
The present invention relates to a CASE (Computer Aided Software Engineering) tool for software development of computers and microcomputers, and in particular to a device for automatically generating source programs of an assembler language or program languages having a jump instruction from a structurized macro language or a tree structure chart.
2. Description of the Background Art
FIG. 1 shows an example of a description of a PAD (Problem Analysis Diagram) chart which is a kind of a conventional tree structure chart. In this specification, a "chart" generally means a tree structure chart, and a "list" generally means source lines of a program. Also, "condition 1", "condition 2" or the like generally mean a state of a flag used for determining a condition in the assembler language.
A PAD chart in FIG. 1 is formed of eleven boxes 300, 302, 304, 306, 308, 310, 312, 314, 316, 318 and 320. The PAD chart is executed downward, and the algorithm of specific processing is described in these series of boxes.
In the PAD chart, dedicated boxes are defined correspondingly to program structures such as condition determination and repetition loop. In the example shown in FIG. 1, boxes 306 and 312 are such dedicated boxes. Source lines in these structures are hierarchically described in the boxes at the right of the dedicated boxes. Thus, contents of box 306 are described in boxes 310, 312, 314, 316 and 318, and contents of box 312 are described in box 320.
The PAD chart is executed downward. When a loop or a jump structure appears, the series of boxes described at the right of the structure in question is executed downward. When execution of the series of boxes is completed, the processing returns to the original structure, and the structure is further executed downward. When the processing reaches the lower end of the chart, the execution is finished.
FIG. 2 shows an example of a description of an "if then else" structure in the conventional PAD chart. The PAD chart will now be described below. In FIG. 2 and the following figures which will be described later, an internal storage format of a graphical file of each structure is shown at a lower right portion of the chart.
Referring to FIG. 2, condition 1 is described in a box of an "if then else" structure. If condition 1 is true, a chart B is executed. If condition 1 is false, a chart C is executed. Thereafter, the program is executed further downward. In FIG. 2, "(true)" and "(false)" are mentioned above and below the box of condition 1. This is implicit declaration that the upper is executed if condition 1=true, and that the lower is executed if condition 1=false. Therefore, these expressions are not actually present on the chart.
In a structure shown at (A) in FIG. 3, chart B is executed if condition 1=true, and nothing is executed if condition 1=false. In the case at (B) in FIG. 3, nothing is executed if condition 1=true, and chart C is executed if condition 1=false.
In both the cases at (A) and (B) in FIG. 3, when execution of the "if then" structure is completed, the program is executed further downward.
FIG. 4 shows an example of a description of a "repeat until" structure. In this structure, chart B is first executed, and then true or false of condition 1 is determined. When condition 1=false, chart B is executed again. If condition 1=true, the "repeat until" structure is completed, and the program is executed further downward.
FIG. 5 shows examples of a description of a "do while" structure. FIG. 5 shows two examples (A) and (B) of a description. These two examples differs from each other only in a representation manner of the box, and more specifically in that vertical lines are added to the left and right sides of the "do while" structure box, respectively, and do not differ from each other in the actual execution order of the program. In the "do while" structure, true or false of condition 2 is first determined. If condition 2=true, chart B is executed, and the control returns to the top for determining condition 2. If condition 2=false, the "do while" structure is finished without executing chart B, and the program is executed further downward. FIG. 5 differs from FIG. 4 in that chart B is first executed at least once in FIG. 4, but chart B may not be executed at all in FIG. 5.
FIG. 6 is an example of a description of an "N+1/2 structure. This structure includes an escape from a loop. In this structure, chart B is first executed, and then true or false of condition 1 is determined. If condition 1=true, the "N+1/2" structure is finished. If condition 1=false, chart C is executed, and the control returns to execution of chart B. When "N+1/2" structure is finished, the program will be executed further downward.
FIG. 7 shows an example of a description of a jump structure. This structure unconditionally jumps to a label A in the program.
FIG. 8 shows a label structure. This structure defines a label name indicating a position in the program.
FIG. 9 is an example of a sequential processing structure. This structure is used for describing processing not accompanied with condition determination and jump.
In the general tree structure charts described above, the jump structure and the loop structure are represented in graphical forms, and only the determination conditions are described in the boxes for graphical forms of the jump and loop.
In the assembler language, condition determination part and jump instruction utilizing results of the determination are often present apart from each other in the source, or are often present over a plurality of lines. Therefore, if it is allowed to describe only determination conditions in a box, as is done in the conventional tree structure chart, unnaturalness becomes remarkable if the tree structure chart is written with the assembler language.
Meanwhile, the assembler language itself has the following problems peculiar to it. In languages such as FORTRAN, C, BASIC, PASCAL and COBOL, grammar/notation are standardized and structurized. Therefore, source lists of these languages can be generated from tree structure charts relatively easily by using dedicated algorithms corresponding to the languages, respectively. However, in the assembler languages used for microcomputer development, there are various kinds of representation manners and commands depending on types of CPUs, and there is no standardized language system. Since hardware depends on the CPUs, there are many instructions, flags and registers which cannot be standardized. Therefore, if the program executed by a microcomputer is to be represented by a tree structure chart, different expressions depending on CPUs must be used. Therefore, in order to automatically generate a source list of the assembler language from such a tree structure chart, it is necessary to prepare a dedicated automatic source generation processing system for each CPU, resulting in an inefficient work.
Some of the assembler language systems used for microcomputer development include both of complementary condition determination instructions, and the other assembler language systems include only one of them. These depend on types of CPUs in various manners. Therefore, it is difficult to generate automatically the source list from the tree structure chart regardless of the types of CPUs, and each CPU requires a dedicated processing system. This also requires an inefficient work for automatic generation of the source program in the assembler language.
For automatic generation of the assembler source from a tree structure chart described in the assembler language, it is necessary to design different assembler automatic source generation systems depending on CPUs, respectively, as described above. For different CPUs, different assembler automatic source generation systems must be designed even for the same processing, respectively, which also results in an insufficient work.
For some CPUs, there are prepared two kinds of jump instructions, which allow jump through whole the address space (which will be referred to as a "LONG JUMP" instruction) and allow jump only by about 128 bytes forward and rearward from a program counter (which will be referred to as a "SHORT JUMP" instruction), respectively. In general, the SHORT JUMP instruction is smaller in byte number than the LONG JUMP instruction, and allows faster execution. Also, the SHORT JUMP instruction advantageously has a smaller program size. Therefore, in the assembler language differentiating these instructions can have a smaller program size and can execute the program in an improved manner.
However, in the conventional tree structure chart, there is no way of differentiating the jump instructions corresponding to the assembler language. Therefore, it is extremely difficult to perform automatic generation of the source list of the assembler language differentiating such instructions from the tree structure chart. As an example of the measure for the above purpose, a processing system may be prepared where the LONG JUMP instruction and SHORT JUMP instruction are automatically determined based on the byte number of the instruction in the source program. However, it is inefficient to prepare the processing system for the foregoing differentiation corresponding to the respective CPUs, and such a system cannot be actually employed.
When the source program is automatically generated, labels which overlap with each other are often generated in the source list on the algorithm of automatic generation. Generation of the labels in the overlapped fashion causes not only an undesirable increase in program size but also difficulty in understanding of program.